github pages

我在上为我的私人项目运行了一些静态网站。 我对这项服务非常满意，因为它支持自定义域，自动重定向到HTTPS并透明地安装SSL证书（通过自动颁发）。 它非常快（感谢内容交付网络），并且非常可靠（我多年来没有遇到任何问题）。 考虑到我免费获得所有这些东西的事实，它目前完全符合我的需求。

但是，它有一个重要的局限性：因为它仅服务于静态网站，所以这意味着没有查询参数，没有在服务器端生成动态内容，没有用于注入任何服务器端配置的选项（例如.htaccess），并且唯一我可以推送到网站根目录的东西是静态资产（例如HTML，CSS，JS，JPEG等）。 通常，这不是大问题。 有很多可用的开源 ，例如默认情况下可从仪表板使用的和在大多数情况下我更喜欢的 。 然而，当您需要实施服务器端传统上可以解决的问题时，全新的挑战开始了。

例如，最近我不得不为我的一个网站更改自定义域名。 保留旧的旧书非常可笑，我不愿意继续浪费金钱。 我找到了一个更便宜的替代方案，并立即面临一个更大的问题：所有搜索引擎的索引中都带有旧名称。 更新索引需要时间，在这种情况下，我将不得不将所有请求重定向到新位置。 理想情况下，我会将每个索引资源重定向到新站点上的等效资源，但是至少，我需要将请求重定向到新的起始页。 我可以访问旧域名的时间足够长，因此可以同时在两个域名上分别运行该站点。

对于这种情况，有一种适当的解决方案应在任何可能的情况下使用：永久重定向或状态代码是重定向HTTP协议中实现的页面的方法。 唯一的问题是，它应该在服务器响应的HTTP标头中的服务器端发生。 但是我唯一可以实现的解决方案是在客户端。 即HTML代码或JavaScript。 我没有考虑JS变体，因为我不想依靠Web浏览器中脚本的支持。 定义任务后，我想起了一个解决方案： <meta http-equiv>和 。 尽管可以用它要求浏览器在指定的秒数后重新加载页面或跳转到另一个URL，但经过一些研究，我发现它比一些我想像的事实和细节要复杂得多。

解决方案

TL; DR （适用于对所有详细信息不感兴趣的人）：简而言之，此解决方案将两个存储库配置为具有自定义域名的静态网站。

在具有旧域的网站上，我重建了网站的整个目录结构，并将以下index.html（包括根目录）分别放在其中：

                                                                      
                                                                          
                                                                                    
             
         
             
                
             
                              
                                                                                                                                                                                 
                                                                                    
             
                                                                         
                 The page been moved to {
     {THE_NEW_URL}}     
             
                                                                        
                                                                                   
     

当有人在旧域上打开资源时，大多数Web浏览器会立即重定向到新网站上的相同资源（由于http-equiv =“ refresh” ）。 对于任何丢失或不存在的资源，在旧网站的根目录中创建内容相似但没有rel =“ canonical”的404.html文件会很有帮助（在这种情况下，因为没有规范页面）。

最后一个难题是 （ rel =“ canonical” ），只要实现的重定向不是永久性的 ，它就可以防止重复内容。 从HTTP响应的角度来看，当并且向搜索引擎指示资源已移动并且应该与新（首选）位置相关联时，就会发生这种情况。

我了解到一些有关http-equiv =“ refresh”和rel =“ canonical”的有趣事实。 HTML元标记http-equiv用于模拟服务器响应中HTTP标头的存在。 也就是说，无法访问Web服务器配置的Web开发人员可以通过从HTML文档（HTTP响应的“主体”）“注入” HTTP标头获得类似的结果。 看来刷新头，它已被用于所有流行的网络浏览器多年， 实际上并不存在 。 至少不作为标准的HTTP标头。 曾经有计划将其添加到HTTP / 1.1规范中，该规范被 （或更高版本），但从未实现。

摘要

查找资源的真实源URL的任务绝非易事。 有不同的方案名称（HTTP，HTTPS），多个查询参数（page.html，page.html？a = 1），可解析为相同IP地址的各种主机名等。所有这些选项使网页看上去与搜索引擎，但页面仍然相同。 当相同的内容发布在独立的Web服务上时，情况甚至更糟。 2009年，Google，Yahoo和Microsoft宣布 ，以允许网站管理员为同一页面的一组可能的URL选择规范（首选）URL，以清理网站上的重复URL。 这有助于搜索引擎选择正确的URL来与内容相关联，还可以改善 。

翻译自:

github pages